stream: cut per-chunk overhead in web streams pipelines - #65437

Reduces per-chunk overhead across common web streams pipelines (fetch body decompression/upload, TextDecoderStream/TextEncoderStream transcoding), targeting workloads that move large payloads in small (e.g. 4 KiB) chunks.

Changes

stream: process CompressionStream chunks without threadpool round trips

CompressionStream/DecompressionStream wrapped a zlib stream.Duplex in the web streams adapters, so every written chunk was dispatched to the threadpool and its completion observed on a later event loop turn. For a 64 MiB body written in 4 KiB chunks that is 16384 threadpool round trips plus the Transform and adapter machinery around them. The classes are now built on a TransformStream that drives the raw zlib/brotli handle synchronously, mirroring the write loop of the zlib streams (same handle setup, same error mapping, same trailing-garbage rejection). Inputs larger than 64 KiB are processed in slices with an event-loop turn in between, so a huge chunk cannot block the loop for its full duration. Output is emitted in up to 64 KiB chunks, either as zero-copy views or as right-sized copies so tiny chunks do not retain large buffers.

stream: fast-path TextEncoderStream chunk encoding

The encode-and-enqueue algorithm was a literal transcription of the spec's per-code-unit loop: it extracted a single-character string, called charCodeAt(), and appended to an accumulator string for every code unit of every chunk (~67 million temporary strings for a 64 MiB payload). The loop's only observable effects are the surrogate hand-off at chunk boundaries and U+FFFD replacement of unpaired surrogates, which TextEncoder.encode() already performs; the transform now handles the chunk boundary explicitly and encodes the rest of the chunk with a single encode() call.

stream: remove unused sync-error destroy plumbing from adapters

The kValidateChunk/kDestroyOnSyncError hooks existed only for the previous Duplex-based compression implementation.

Benchmarks

64 MiB of log-like text, 4 KiB chunks, best of 5, idle Linux x64. Baseline is v27.0.0-nightly20260819 (current main); "this PR" is a from-source build of this branch.

End-to-end pipelines

Isolated stages (64 MiB through just the stage, 4 KiB chunks)

End-to-end wall time is capped by physical floors on this machine (gzipSync of this payload is ~620 ms of raw CPU; gunzipSync is ~139 ms; UTF-8 decode+encode of 64 MiB is ~84 ms). After this PR the remaining non-codec overhead on upload is ~130 ms (~8 µs/chunk) and on download is well under the gunzip floor. A literal 10x on wall time is not available for upload/download/subprocess; the one place a full 10x+ existed was the encoder stage.

Adds benchmark/webstreams/compression.js and benchmark/webstreams/encoding.js.

Behavior notes

• Compression/decompression now runs on the JS thread. For small chunks this strictly removes latency (the deflate of a 4 KiB chunk costs far less than a threadpool dispatch); for oversized chunks the input is sliced with event-loop yields to bound blocking.
• Decompressed/compressed output chunks may now be emitted as Uint8Array views over a larger ArrayBuffer (when at least half the buffer is filled) rather than always exact-sized copies. Those views never share memory with one another: the backing buffer is retired after a view is emitted.
• Node.js-specific behaviors are preserved and covered by tests: string chunks are accepted, null rejects with ERR_STREAM_NULL_VALUES, non-BufferSource chunks reject with ERR_INVALID_ARG_TYPE, trailing garbage rejects with ERR_TRAILING_JUNK_AFTER_STREAM_END (all TypeErrors), and 'brotli' remains supported.

Testing

Local out/Release/node (this branch): 30 targeted tests, all passing, including test-whatwg-webstreams-compression, test-webstreams-compression-bad-chunks, test-webstreams-decompression-reject-trailing, test-webstreams-compression-buffer-source, test-compression-decompression-stream, test-zlib-type-error, test-whatwg-webstreams-encoding, the Readable.toWeb / adapters tests, and WPT compression, encoding, and streams.